…oolsMenu items to null

Two related fixes surfaced while putting together a demo app:

1. Hot Reload survives hook-order / hook-type edits.

   Editing a component to add, remove, or reorder hooks (or change a
   hook's generic type) used to leave the app stuck on the error
   fallback after the very next save — the surviving RenderContext had
   the *previous* hook list pinned by index, and the new Render() body
   couldn't line up against it. The dev loop died until the user
   restarted the app.

   New behavior: when a hook-order/type mismatch surfaces during a
   render that was triggered by .NET Hot Reload, the host runs effect
   cleanups, drops the hook list, and re-renders from scratch. Hook
   state is lost (we cannot reliably re-key arbitrary surviving values
   onto a shape that may have changed) but the app keeps running.

   - New HookOrderException : InvalidOperationException so the host
     can sniff the specific subtype without changing existing
     `catch (InvalidOperationException)` semantics for callers.
   - All 10 hook-order/type-mismatch throw sites in RenderContext.cs
     converted from InvalidOperationException to HookOrderException.
     Cross-thread setter and UseNavigation lookup throws are
     intentionally left as plain InvalidOperationException — neither
     is a hot-reload-recoverable failure.
   - RenderContext.ResetForHotReload(): runs cleanups, clears hook
     list, resets index. New API, internal-only.
   - HotReloadService.UpdatePending: signals "the next render is a
     hot-reload-induced render". Set by UpdateApplication, consumed
     (capture-and-clear) by ReactorHostControl.Render at the top of
     the render attempt.
   - ReactorHostControl.Render(): catch (HookOrderException) when
     (hotReloadRender) recovers; any subsequent failure on the
     recovery render falls through to the existing ShowErrorFallback
     path. The capture-and-clear pattern guarantees at-most-once
     recovery per UpdateApplication, so genuinely broken hook code
     surfaces the error fallback once instead of an infinite reset
     loop.

   Tests:
   - 5 existing Assert.Throws<InvalidOperationException> hook-order
     tests tightened to Assert.Throws<HookOrderException>. The looser
     assertion was incidental — these tests have always been about a
     specific contract that now has a specific type.
   - 2 new tests in HookStateRefactorTests.cs:
     ResetForHotReload_RunsCleanups_And_ClearsHooks_So_Next_Render_Sees_Fresh_Sequence
     and ResetForHotReload_Allows_Different_Hook_Type_At_Same_Index.

2. DevtoolsMenu items factory defaults to null.

   Calling DevtoolsMenu() with no arguments to get the built-in
   toggles (Highlight reconcile / Show layout cost) used to require
   passing a no-op `() => Array.Empty<MenuFlyoutItemBase>()`. The
   implementation already null-coalesces inside (`items?.Invoke()
   ?.ToArray() ?? Array.Empty<...>()`) — the parameter was just
   non-nullable. Changed to `Func<...>? items = null` so
   `DevtoolsMenu()` with no args is valid.

Test results:
- dotnet test tests/Reactor.Tests: 6821 passed, 0 failed (2 new).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- HotReloadService.UpdatePending now backed by an int with
  Volatile.Write/Read on the producer side and
  Interlocked.Exchange via ConsumeUpdatePending() on the consumer
  side. UpdateApplication runs on a hot-reload runtime thread while
  Render runs on the UI dispatcher; the previous read-then-write
  pattern had a window where a concurrent UpdateApplication could
  raise the flag between Render's read and clear, losing the new
  pending update. Single CAS removes the window.

- HotReloadService XML doc rewritten to match the actual contract:
  the flag is consumed (atomically) at the start of each render
  attempt, not "after the render completes" as the previous comment
  said.

- ReactorHostControl.Render: extracted a RecoverFromHookOrder local
  function so the two HookOrderException catch branches
  (component-mode / function-mode) share a single log → reset →
  RequestRender sequence. Future tweaks (telemetry, throttling,
  additional reset steps) edit one place.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>